
\chapter{Object Files}

\section{ELF Header}

\subsection{Machine Information}

\subsubsection{Programming Model}

As described in Section \ref{intro}, binaries using the \xARCH instruction
set may program to either a 32-bit model (ILP32) or to a 64-bit model (LP64).
This specification describes both binaries that use the ILP32 and the LP64
model.

\subsubsection{File Class}

For \xARCH ILP32 objects, the file class value in \texttt{e_ident[EI_CLASS]}
must be \texttt{ELFCLASS32}. For \xARCH LP64 objects, the file class value
must be \texttt{ELFCLASS64}.

\subsubsection{Data Encoding}

For the data encoding in \texttt{e_ident[EI_DATA]}, \xARCH objects use
\texttt{ELFDATA2LSB}.

\subsubsection{Processor identification}

Processor identification resides in the ELF headers
\texttt{e_machine} member and must have the value
\texttt{EM_X86_64}.\footnote{The value of this identifier is 62.}

\subsection{Number of Program Headers}

The \texttt{e_phnum} member contains the number of entries in the program
header table. The product of
\texttt{e_phentsize} and \texttt{e_phnum} gives the table's size in bytes.
If a file has no program header table, \texttt{e_phnum} holds the value zero.

If the number of program headers is greater than or equal to
\code{PN_XNUM} (0xffff), this member has the value \code{PN_XNUM} (0xffff).
The actual number of program header table entries is contained in
the \texttt{sh_info} field of the section header at index 0. Otherwise,
the \texttt{sh_info} member of the initial entry contains the value zero.

\section{Sections}

\subsection{Section Flags}

In order to allow linking object files of different code models, it is
necessary to provide for a way to differentiate those sections which may hold
more than 2GB from those which may not. This is accomplished by defining a
processor-specific section attribute flag for \code{sh\_flag}
(see table~\ref{sh_flags}).

\begin{table}[H]
\Hrule
  \caption{\xARCH Specific Section Header Flag, \code{sh\_flags}}
  \label{sh_flags}
  \begin{center}
    \begin{tabular}[t]{l|l}
      \multicolumn{1}{c}{Name} & \multicolumn{1}{c}{Value} \\
      \hline
      \texttt{SHF_X86_64_LARGE} & \texttt{0x10000000}
    \end{tabular}
  \end{center}
\Hrule
\end{table}

\begin{description}
 \item[\code{SHF\_X86_64\_LARGE}] If an object file section does
   {\em not} have
   this flag set, then it may not hold more than 2GB and
   can be freely referred to in objects using smaller code models.
   Otherwise, only objects using larger code models can refer to them.
   For example, a medium code model object can refer to data in a
   section that sets this flag besides being able to refer to data in a
   section that does not set it; likewise, a small code model object can
   refer only to code in a section that does not set this flag.
\end{description}

\subsection{Section types}

\begin{table}[H]
\Hrule
  \caption{Section Header Types}
  \begin{center}
    \begin{tabular}[t]{l|l}
      \multicolumn{1}{c}{sh_type name} & \multicolumn{1}{c}{Value} \\
      \hline
      \texttt{SHT_X86_64_UNWIND} & \texttt{0x70000001}
    \end{tabular}
  \end{center}
\Hrule
\end{table}

\begin{description}
 \item[SHT_X86_64_UNWIND]
        This section contains unwind function table entries for
        stack unwinding.  The contents are described in
        Section~\ref{sec_eh_frame} of this document.
\end{description}

\subsection{Special Sections}

\begin{table}[H]
\Hrule
  \caption{Special sections}
  \begin{center}
    \begin{tabular}[t]{l|l|l}
      \multicolumn{1}{c}{Name} & \multicolumn{1}{c}{Type}
       & \multicolumn{1}{c}{Attributes} \\
      \hline
      \texttt{.got} & \texttt{SHT_PROGBITS} & \texttt{SHF_ALLOC+SHF_WRITE} \\
      \texttt{.plt}&\texttt{SHT_PROGBITS} & \texttt{SHF_ALLOC+SHF_EXECINSTR} \\
      \texttt{.eh_frame} & \texttt{SHT_X86_64_UNWIND} & \texttt{SHF_ALLOC}
    \end{tabular}
  \end{center}
\Hrule
\end{table}

\begin{description}
 \item[.got] This section holds the global offset table.
 \item[.plt] This section holds the procedure linkage table.
 \item[.eh_frame] This section holds the unwind function table.
                      The contents are described in Section~\ref{sec_eh_frame}
                      of this document.
\end{description}

The additional sections defined in table~\ref{large_sections} are used
by a system supporting the large code model.

\begin{table}[H]
\Hrule
  \caption{Additional Special Sections for the Large Code Model}
  \myfontsize
  \label{large_sections}
  \begin{center}
    \begin{tabular}[t]{l|l|l}
      \multicolumn{1}{c}{Name} & \multicolumn{1}{c}{Type}
       & \multicolumn{1}{c}{Attributes} \\
      \hline
      \texttt{.lbss} & \texttt{SHT_NOBITS} &
         \texttt{SHF_ALLOC+SHF_WRITE+SHF_X86_64_LARGE} \\
      \texttt{.ldata} & \texttt{SHT_PROGBITS} &
         \texttt{SHF_ALLOC+SHF_WRITE+SHF_X86_64_LARGE} \\
      \texttt{.ldata1} & \texttt{SHT_PROGBITS} &
         \texttt{SHF_ALLOC+SHF_WRITE+SHF_X86_64_LARGE} \\
      \texttt{.lgot} & \texttt{SHT_PROGBITS} &
         \texttt{SHF_ALLOC+SHF_WRITE+SHF_X86_64_LARGE} \\
      \texttt{.lplt} & \texttt{SHT_PROGBITS} &
         \texttt{SHF_ALLOC+SHF_EXECINSTR+SHF_X86_64_LARGE} \\
      \texttt{.lrodata} & \texttt{SHT_PROGBITS} &
         \texttt{SHF_ALLOC+SHF_X86_64_LARGE} \\
      \texttt{.lrodata1} & \texttt{SHT_PROGBITS} &
         \texttt{SHF_ALLOC+SHF_X86_64_LARGE} \\
      \texttt{.ltext} & \texttt{SHT_PROGBITS} &
         \texttt{SHF_ALLOC+SHF_EXECINSTR+SHF_X86_64_LARGE} \\
    \end{tabular}
  \end{center}
\Hrule
\end{table}

In order to enable static linking of objects using different code
models, the following section ordering is suggested:

\begin{description}
  \item[\code{.plt .init .fini .text .got .rodata .rodata1 .data .data1
  .bss}] These sections can have a combined size of up to 2GB.
  \item[\code{.lplt .ltext .lgot .lrodata .lrodata1 .ldata .ldata1
  .lbss}] These sections plus the above can have a combined size of up
   to 16EB.
\end{description}

\subsection{EH\_FRAME sections}
\label{sec_eh_frame}

The call frame information needed for unwinding the stack is output into
one or more ELF sections of type \code{SHT_X86_64_UNWIND}. In the simplest
case there
will be one such section per object file and it will be named
\code{.eh_frame}.  An \code{.eh_frame} section consists of one or more
subsections. Each subsection contains a CIE (Common Information Entry)
followed by varying number of FDEs (Frame Descriptor Entry). A FDE
corresponds to an explicit or compiler generated function in a
compilation unit, all FDEs can access the CIE that begins their
subsection for data.  If the code for a function is not one contiguous
block, there will be a separate FDE for each contiguous sub-piece.

If an object file contains C++ template instantiations there shall be
a separate CIE immediately preceding each FDE corresponding to an
instantiation.

Using the preferred encoding specified below, the \code{.eh_frame} section can
be entirely resolved at link time and thus can become part of the
text segment.

\code{EH_PE} encoding below refers to the pointer encoding as specified in the
enhanced LSB Chapter 7 for \code{Eh_Frame_Hdr}.

\begin{table}[H]
\Hrule
\caption{Common Information Entry (CIE)}
\label{format-cie}
\begin{center}
\begin{tabular}{p{7em}|l|p{17em}}
  \multicolumn{1}{c}{Field}
         & \multicolumn{1}{c}{Length (byte)}
         & \multicolumn{1}{c}{Description} \\ \hline
  Length & 4 & Length of the CIE (not including this 4-byte field) \\
  CIE id & 4 & Value 0 for \code{.eh_frame} (used to distinguish CIEs and
		  FDEs when scanning the section) \\
  Version & 1 & Value One (1) \\
  CIE Augmentation String & string & Null-terminated string with legal
     values being "" or 'z' optionally followed by single occurrances of
     'P', 'L', or 'R' in any order.  The presence of character(s) in the
     string dictates the content of field 8, the Augmentation Section.  Each
     character has one or two associated operands in the AS (see
     table~\ref{format-cieaug} for which ones).  Operand order
     depends on position in the string ('z' must be first). \\
  Code Align Factor & uleb128 & To be multiplied with the
    "Advance Location" instructions in the Call Frame Instructions \\
  Data Align Factor & sleb128 & To be multiplied with all offsets
                                in the Call Frame Instructions \\
  Ret Address Reg & 1/uleb128 &  A "virtual" register representation
                                 of the return address. In Dwarf V2,
			         this is a byte, otherwise it is
			         uleb128. It is a byte in gcc 3.3.x \\
  Optional CIE Augmentation Section & varying & Present if Augmentation
                     String in Augmentation Section field 4 is not 0. 
		     See table~\ref{format-cieaug} for the content. \\
  Optional Call Frame Instructions & varying & \\
\hline
    \end{tabular}
  \end{center}
\Hrule
\end{table}

\begin{table}[H]
\Hrule
\caption{CIE Augmentation Section Content}
\label{format-cieaug}
\begin{center}
\begin{tabular}{l|p{7em}|l|p{14em}}
  \multicolumn{1}{c}{Char}
         & \multicolumn{1}{c}{Operands}
         & \multicolumn{1}{c}{Length (byte)}
         & \multicolumn{1}{c}{Description} \\ \hline
  z & size & uleb128 & Length of the remainder of the
                                        Augmentation Section \\
  P & personality_enc & 1 & Encoding specifier - preferred
                            value is a pc-relative, signed
                            4-byte \\
    & personality routine & (encoded) & Encoded pointer to personality
                                        routine (actually to the PLT
                                        entry for the personality
                                        routine) \\
  R & code_enc & 1 & Non-default encoding for the
                     code-pointers (FDE members
                     \code{initial_location} and \code{address_range}
                     and the operand for \code{DW_CFA_set_loc})
                     - preferred value is pc-relative,
                     signed 4-byte \\
  L & lsda_enc & 1 & FDE augmentation bodies may contain
		     LSDA pointers. If so they are encoded
		     as specified here -
		     preferred value is pc-relative, signed 4-byte possibly
		     indirect thru a GOT entry \\
\hline
    \end{tabular}
  \end{center}
\Hrule
\end{table}

\begin{table}[H]
\Hrule
\caption{Frame Descriptor Entry (FDE)}
\label{format-fde}
\begin{center}
\begin{tabular}{p{7em}|l|p{17em}}
  \multicolumn{1}{c}{Field}
         & \multicolumn{1}{c}{Length (byte)}
         & \multicolumn{1}{c}{Description} \\ \hline
  Length & 4 & Length of the FDE (not including this 4-byte field) \\
  CIE pointer & 4 & Distance from this field to the
		    nearest preceding CIE (the value is subtracted from the
		    current address). This value can never be zero and thus can
		    be used to distinguish CIE's and FDE's when scanning the
		    \code{.eh_frame} section \\
  Initial Location & var & Reference to the function code 
                           corresponding to this FDE.
                           If 'R' is missing from the CIE
                           Augmentation String, the field is an
                           8-byte absolute pointer. Otherwise,
                           the corresponding \code{EH_PE} encoding in the 
                           CIE Augmentation Section is used to 
                           interpret the reference \\
  Address Range & var & Size of the function code corresponding
                       to this FDE.
                       If 'R' is missing from the CIE
                       Augmentation String, the field is an
                       8-byte unsigned number. Otherwise,
                       the size is determined by the
                       corresponding \code{EH_PE} encoding in the 
                       CIE Augmentation Section (the
                       value is always absolute) \\
  Optional FDE Augmentation Section & var & Present if CIE Augmentation
                     String is non-empty.
		     See table~\ref{format-fdeaug} for the content. \\
  Optional Call Frame Instructions & var & \\
\hline
    \end{tabular}
  \end{center}
\Hrule
\end{table}

\begin{table}[H]
\Hrule
\caption{FDE Augmentation Section Content}
\label{format-fdeaug}
\begin{center}
\begin{tabular}{l|p{5em}|l|p{15em}}
  \multicolumn{1}{c}{Char}
         & \multicolumn{1}{c}{Operands}
         & \multicolumn{1}{c}{Length (byte)}
         & \multicolumn{1}{c}{Description} \\ \hline
  z & length & uleb128 & Length of the remainder of the
                                        Augmentation Section \\
  L & LSDA & var & LSDA pointer, encoded in the
                   format specified by the
                   corresponding operand in the CIE's
                   augmentation body. (only present if length > 0). \\
\hline
    \end{tabular}
  \end{center}
\Hrule
\end{table}
The existence and size of the optional call frame instruction area must
be computed
based on the overall size and the offset reached while scanning the
preceding fields of the CIE or FDE.

The overall size of a \code{.eh_frame} section is given in the ELF section
header.  The only way to determine the number of entries is to scan
the section until the end, counting entries as they are encountered.

\section{Symbol Table}

The discussion of "Function Addresses" in Section~\ref{function_addresses}
defines some special values for symbol table fields.

The \texttt{STT_GNU_IFUNC}
\footnote{It is specified in {\bf Linux Extensions to gABI}
at \url{https://github.com/hjl-tools/linux-abi}}
symbol type is optional. It is the same as
\texttt{STT_FUNC} except that it always points to a function or piece of
executable code which takes no arguments and returns a function pointer.
If an \texttt{STT_GNU_IFUNC} symbol is referred to by a relocation, then
evaluation of that relocation is delayed until load-time.  The value
used in the relocation is the function pointer returned by an invocation
of the \texttt{STT_GNU_IFUNC} symbol.
 
The purpose of the \texttt{STT_GNU_IFUNC} symbol type is to allow the
run-time to select between multiple versions of the implementation of
a specific function.  The selection made in general will take the
currently available hardware into account and select the most
appropriate version.

\section{Relocation}

\subsection{Relocation Types}

Figure~\ref{reloc_fields} shows the allowed relocatable fields.

\begin{figure}[H]
\label{reloc_fields}
\Hrule
  \caption{Relocatable Fields}
\begin{center}
  \begin{picture}(360,190)
    \put(0,150){\framebox(50, 33){7\hfill\textit{word8}\hfill 0}}
    \put(0,100){\framebox(90, 33){15\hfill\textit{word16}\hfill 0}}
    \put(0,50){\framebox(180, 33){31\hfill\textit{word32}\hfill 0}}
    \put(0,0){\framebox(360, 33){63\hfill\textit{word64}\hfill 0}}
  \end{picture}
\end{center}
\Hrule
\end{figure}

\noindent
\begin{tabular*}{\textwidth}{l@{\extracolsep{\fill}}p{4in}}
\textit{word8} & This specifies a 8-bit field occupying 1 byte.\\
\textit{word16} & This specifies a 16-bit field occupying 2 bytes
                  with arbitrary byte alignment.  These values use
                  the same byte order as other word values in the
                  \xARCH architecture. \\
\textit{word32} & This specifies a 32-bit field occupying 4 bytes
                  with arbitrary byte alignment.  These values use
                  the same byte order as other word values in the
                  \xARCH architecture. \\
\textit{word64} & This specifies a 64-bit field occupying 8 bytes
                  with arbitrary byte alignment.  These values use
                  the same byte order as other word values in the
                  \xARCH architecture. \\
\textit{wordclass} & This specifies \textit{word64} for LP64 and
		     specifies \textit{word32} for ILP32. \\
\end{tabular*}

The following notations are used for specifying relocations in table~
\ref{tab-relocations}:
\begin{description}
\item[A] Represents the addend used to compute the value of the
  relocatable field.
\item[B] Represents the base address at which a shared object has been
  loaded into memory during execution.  Generally, a shared object is
  built with a 0 base virtual address, but the execution address will
  be different.
\item[G] Represents the offset into the global offset table at which 
  the relocation entry's symbol will reside during execution.
\item[GOT] Represents the address of the global offset table.
\item[L] Represents the place (section offset or address) of the
  \textindex{Procedure Linkage Table} entry for a symbol.
\item[P] Represents the place (section offset or address) of the
  storage unit being relocated (computed using \code{r_offset}).
\item[S] Represents the value of the symbol whose index resides in the
  relocation entry.
\item[Z] Represents the size of the symbol whose index resides in the
  relocation entry.
\end{description}

The \xARCH LP64 ABI architecture uses only \texttt{Elf64_Rela} relocation
entries with explicit addends.  The \code{r_addend} member serves as
the relocation addend.

The \xARCH ILP32 ABI architecture uses only \texttt{Elf32_Rela} relocation
entries in relocatable files.  Executable
files or shared objects may use either \texttt{Elf32_Rela}
or \texttt{Elf32_Rel} relocation entries.

\begin{table}[H]
\Hrule
  \caption{Relocation Types}
  \myfontsize
  \label{tab-relocations}
  \begin{center}
    \begin{tabular}[t]{l|r|l|l}
      \multicolumn{1}{c}{Name} & 
      \multicolumn{1}{c}{Value} & 
      \multicolumn{1}{c}{Field} & 
      \multicolumn{1}{c}{Calculation} \\
      \hline
      \texttt{R_X86_64_NONE}  & 0 & none & none \\
      \texttt{R_X86_64_64}    & 1 & \textit{word64} & \texttt{S + A} \\
      \texttt{R_X86_64_PC32}  & 2 & \textit{word32} & \texttt{S + A - P} \\
      \texttt{R_X86_64_GOT32} & 3 & \textit{word32} & \texttt{G + A} \\
      \texttt{R_X86_64_PLT32} & 4 & \textit{word32} & \texttt{L + A - P} \\
      \texttt{R_X86_64_COPY}  & 5 & none            & none \\
      \texttt{R_X86_64_GLOB_DAT} & 6 & \textit{wordclass} & \texttt{S} \\
      \texttt{R_X86_64_JUMP_SLOT} & 7 & \textit{wordclass} & \texttt{S} \\
      \texttt{R_X86_64_RELATIVE} & 8 & \textit{wordclass} & \texttt{B + A} \\
      \texttt{R_X86_64_GOTPCREL} & 9 & \textit{word32} & \texttt{G + GOT + A - P} \\
      \texttt{R_X86_64_32}    & 10 & \textit{word32} & \texttt{S + A} \\
      \texttt{R_X86_64_32S}   & 11 & \textit{word32} & \texttt{S + A} \\
      \texttt{R_X86_64_16}    & 12 & \textit{word16} & \texttt{S + A} \\
      \texttt{R_X86_64_PC16}  & 13 & \textit{word16} & \texttt{S + A - P} \\
      \texttt{R_X86_64_8}     & 14 & \textit{word8} & \texttt{S + A} \\
      \texttt{R_X86_64_PC8}   & 15 & \textit{word8} & \texttt{S + A - P} \\
      \texttt{R_X86_64_DTPMOD64}   & 16 & \textit{word64} &  \\
      \texttt{R_X86_64_DTPOFF64}   & 17 & \textit{word64} &  \\
      \texttt{R_X86_64_TPOFF64}   & 18 & \textit{word64} &  \\
      \texttt{R_X86_64_TLSGD}   & 19 & \textit{word32} &  \\
      \texttt{R_X86_64_TLSLD}   & 20 & \textit{word32} &  \\
      \texttt{R_X86_64_DTPOFF32}   & 21 & \textit{word32} &  \\
      \texttt{R_X86_64_GOTTPOFF}   & 22 & \textit{word32} &  \\
      \texttt{R_X86_64_TPOFF32}   & 23 & \textit{word32} &  \\
      \texttt{R_X86_64_PC64} $^\dagger$ & 24 & \textit{word64} & \texttt{S + A - P} \\
      \texttt{R_X86_64_GOTOFF64} $^\dagger$ & 25 & \textit{word64} & \texttt{S + A - GOT} \\
      \texttt{R_X86_64_GOTPC32} & 26 & \textit{word32} & \texttt{GOT + A - P} \\
      \texttt{R_X86_64_SIZE32} & 32 & \textit{word32} & \texttt{Z + A} \\
      \texttt{R_X86_64_SIZE64} $^\dagger$ & 33 & \textit{word64} & \texttt{Z + A} \\
      \texttt{R_X86_64_GOTPC32_TLSDESC} & 34 & \textit{word32} &  \\
      \texttt{R_X86_64_TLSDESC_CALL} & 35 & none &  \\
      \texttt{R_X86_64_TLSDESC} & 36 & \textit{word64}$\times 2$ & \\
      \texttt{R_X86_64_IRELATIVE} & 37 & \textit{wordclass} & \texttt{indirect (B + A)}\\
      \texttt{R_X86_64_RELATIVE64} $^{\dagger\dagger}$ & 38 & \textit{word64} & \texttt{B + A} \\
      \texttt{Deprecated} & 39 & & \\
      \texttt{Deprecated} & 40 & & \\
      \texttt{R_X86_64_GOTPCRELX} & 41 & \textit{word32} & \texttt{G + GOT + A - P} \\
      \texttt{R_X86_64_REX_GOTPCRELX} & 42 & \textit{word32} & \texttt{G + GOT + A - P} \\
     \cline{1-4}
    \multicolumn{4}{l}{\small $^\dagger$ This relocation is used only for LP64.}\\
    \multicolumn{4}{l}{\small $^{\dagger\dagger}$ This relocation only
    appears in ILP32 executable files or shared objects.}\\
    \end{tabular}
  \end{center}
\Hrule
\end{table}

The special semantics for most of these relocation types are identical
to those used for the \intelabi.  \footnote{Even though
  the \xARCH architecture supports IP-relative addressing modes, a GOT
  is still required since the offset from a particular instruction to
  a particular data item cannot be known by the static linker.}
\footnote{Note that the \xARCH architecture assumes that offsets into
  GOT are 32-bit values, not 64-bit values.  This choice means that a
  maximum of $2^{32}/8 = 2^{29}$ entries can be placed in the GOT.
  However, that should be more than enough for most programs.  In the
  event that it is not enough, the linker could create multiple GOTs.
  Because 32-bit offsets are used, loads of global data do not require
  loading the offset into a displacement register; the base plus
  immediate displacement addressing form can be used.}

\begin{sloppypar}
The \texttt{R_X86_64_GOTPCREL} relocation has different semantics from the
\texttt{R_X86_64_GOT32} or equivalent i386 \texttt{R_386_GOTPC} relocation.
In particular, because the \xARCH architecture has an addressing mode relative
to the instruction pointer, it is possible to load an address from the GOT
using a single instruction.  The calculation done by the
\texttt{R_X86_64_GOTPCREL} relocation gives the difference between the location
in the GOT where the symbol's address is given and the location where the
relocation is applied.
\end{sloppypar}

For the occurrence of \code{name@GOTPCREL} in the following assembler
instructions:

\begin{footnotesize}
\begin{verbatim}
        call       *name@GOTPCREL(%rip)
        jmp        *name@GOTPCREL(%rip)
        mov        name@GOTPCREL(%rip), %reg
        test       %reg, name@GOTPCREL(%rip)
        binop      name@GOTPCREL(%rip), %reg
\end{verbatim}
\end{footnotesize}

\noindent
\begin{sloppypar}
where \code{binop} is one of \code{adc}, \code{add}, \code{and},
\code{cmp}, \code{or}, \code{sbb}, \code{sub}, \code{xor}
instructions, the \texttt{R_X86_64_GOTPCRELX} relocation,
or the \texttt{R_X86_64_REX_GOTPCRELX} relocation if the
\code{REX} prefix is present, should be generated,
instead of the \texttt{R_X86_64_GOTPCREL} relocation.  See also
section~\ref{opt_gotpcrelx}.
\end{sloppypar}

\begin{sloppypar}
The \texttt{R_X86_64_32} and \texttt{R_X86_64_32S} relocations truncate
the computed value to 32-bits.  The linker must verify that the
generated value for the \texttt{R_X86_64_32} (\texttt{R_X86_64_32S})
relocation zero-extends (sign-extends) to the original 64-bit value.
\end{sloppypar}

\begin{sloppypar}
A program or object file using \texttt{R_X86_64_8},
\texttt{R_X86_64_16}, \texttt{R_X86_64_PC16} or \texttt{R_X86_64_PC8}
relocations is not conformant to this ABI, these relocations are only
added for documentation purposes.  The \texttt{R_X86_64_16}, and
\texttt{R_X86_64_8} relocations truncate the computed value to 16-bits
resp. 8-bits.
\end{sloppypar}

\begin{sloppypar}
The relocations \texttt{R_X86_64_DTPMOD64},
\texttt{R_X86_64_DTPOFF64}, \texttt{R_X86_64_TPOFF64},
\texttt{R_X86_64_TLSGD}, \texttt{R_X86_64_TLSLD},
\texttt{R_X86_64_DTPOFF32}, \texttt{R_X86_64_GOTTPOFF} and
\texttt{R_X86_64_TPOFF32} are listed for completeness.  They are part
of the Thread-Local Storage ABI extensions and are documented in the
document called ``ELF Handling for Thread-Local
Storage''\footnote{This document is currently available via
  \raggedright\url{http://www.akkadia.org/drepper/tls.pdf}}\index{Thread-Local
  Storage}.  The relocations \texttt{R_X86_64_GOTPC32_TLSDESC},
\texttt{R_X86_64_TLSDESC_CALL} and \texttt{R_X86_64_TLSDESC} are also
used for Thread-Local Storage, but are not documented there as of this
writing.  A description can be found in the document ``Thread-Local
Storage Descriptors for IA32 and AMD64/EM64T''\footnote{This document
  is currently available via
  \raggedright\url{http://www.fsfla.org/~lxoliva/writeups/TLS/RFC-TLSDESC-x86.txt}}.
\end{sloppypar}

In order to make this document self-contained, a description of the
TLS relocations follows.

The \reg{fs} segment register is used to implement the thread pointer.
The linear address of the thread pointer is stored at offset 0 relative
to the \reg{fs} segment register.  The following code loads the thread
pointer in the \reg{rax} register:

\begin{footnotesize}
\begin{verbatim}
        movq        %fs:0, %rax
\end{verbatim}
\end{footnotesize}

\begin{sloppypar}
\texttt{R_X86_64_DTPMOD64} resolves to the index of the dynamic thread
vector entry that points to the base address of the TLS block
corresponding to the module that defines the referenced symbol.
\texttt{R_X86_64_DTPOFF64} and \texttt{R_X86_64_DTPOFF32} compute the
offset from the pointer in that entry to the referenced symbol.  The
linker generates such relocations in adjacent entries in the GOT, in
response to \texttt{R_X86_64_TLSGD} and \texttt{R_X86_64_TLSLD}
relocations.  If the linker can compute the offset itself, because the
referenced symbol binds locally, the relocations \texttt{R_X86_64_64} and \texttt{R_X86_64_32} may be used instead.
Otherwise, such relocations are always in pairs, such that the
\texttt{R_X86_64_DTPOFF64} relocation applies to the word64 right past the
corresponding \texttt{R_X86_64_DTPMOD64} relocation.
\end{sloppypar}

\texttt{R_X86_64_TPOFF64} and \texttt{R_X86_64_TPOFF32} resolve to the
offset from the thread pointer to a thread-local variable.  The former
is generated in response to \texttt{R_X86_64_GOTTPOFF}, that resolves
to a PC-relative address of a GOT entry containing such a 64-bit
offset.

\texttt{R_X86_64_TLSGD} and \texttt{R_X86_64_TLSLD} both resolve to
PC-relative offsets to a \texttt{DTPMOD} GOT entry.  The difference
between them is that, for \texttt{R_X86_64_TLSGD}, the following GOT entry will
contain the offset of the referenced symbol into its TLS block,
whereas, for \texttt{R_X86_64_TLSLD}, the following GOT entry will contain the
offset for the base address of the TLS block.  The idea is that adding
this offset to the result of \texttt{R_X86_64_DTPMOD32} for a symbol ought to
yield the same as the result of \texttt{R_X86_64_DTPMOD64} for the same symbol.

\texttt{R_X86_64_TLSDESC} resolves to a pair of word64s, called TLS
Descriptor, the first of which is a pointer to a function, followed by
an argument.  The function is passed a pointer to the this pair of
entries in \%rax and, using the argument in the second entry, it must
compute and return in \%rax the offset from the thread pointer to the
symbol referenced in the relocation, without modifying any registers
other than processor flags.  \texttt{R_X86_64_GOTPC32_TLSDESC}
resolves to the PC-relative address of a TLS descriptor corresponding
to the named symbol.  \texttt{R_X86_64_TLSDESC_CALL} must annotate the
instruction used to call the TLS Descriptor resolver function, so as
to enable relaxation of that instruction.

\texttt{R_X86_64_IRELATIVE} is similar to \texttt{R_X86_64_RELATIVE}
except that the value used in this relocation is the program address
returned by the function, which takes no arguments, at the address of
the result of the corresponding \texttt{R_X86_64_RELATIVE} relocation.

One use of the \texttt{R_X86_64_IRELATIVE} relocation is to avoid name
lookup for the locally defined \texttt{STT_GNU_IFUNC} symbols at
load-time.  Support for this relocation is optional, but is required for
the \texttt{STT_GNU_IFUNC} symbols.

\subsection{Large Models}

In order to extend both the PLT and the GOT beyond 2GB, it
is necessary to add appropriate relocation types to handle
full 64-bit addressing.  See figure~\ref{large_relocation_types}.

\begin{table}[H]
\Hrule
\caption{Large Model Relocation Types}\label{large_relocation_types}
\begin{footnotesize}
\begin{tabular}{|l|l|l|l|}
\hline
Name                        &  Value &   Field   & Calculation            \\
\hline
\code{R_X86_64_GOT64}       &  27    &   word64  & \code{G + A}           \\
\hline
\code{R_X86_64_GOTPCREL64}  &  28    &   word64  & \code{G + GOT - P + A} \\
\hline                                                 
\code{R_X86_64_GOTPC64}     &  29    &   word64  & \code{GOT - P + A}     \\
\hline
\code{Deprecated}           &  30    &           &                        \\
\hline
\code{R_X86_64_PLTOFF64}    &  31    &   word64  & \code{L - GOT + A}     \\
\hline
\end{tabular}
\end{footnotesize}
\end{table}


%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "abi"
%%% End: 
